@fionaRowan this is a very well-written PR!

I like the idea of your second point: allow the user to configure which date to use. For instance, Hugo also uses publishDate, and it would be helpful to have that choice.

But, how should the user pass that field?

option 1:

slug: "{{fields.date.year}}-{{fields.date.month}}-{{fields.date.day}}-{{slug}}"

The original proposal from #6801. It feels too verbose, and .year sounds like a field, not a modifier.

option 2:

slug: "{{fields.date | date("YYYY-MM-DD)}}-{{slug}}"

This matches your option 3, I like it better. If I understand correctly, this is possible if we merge #6690?

In any case, I would first merge what you did here, because it's a well-rounded PR. Just let me know once you complete the testing, and please share your thoughts on how to continue.

thanks for the thorough review, @martinjagodic ! to respond to some of your feedback and questions below~

I like the idea of your second point: allow the user to configure which date to use. For instance, Hugo also uses publishDate, and it would be helpful to have that choice.

But, how should the user pass that field?

I believe inferring the date field takes into account "synonyms", so this change should result in picking the first of those date “synonyms” - I added a couple tests in my last commit to be sure.

that said, if we'd prefer not to infer which date field to use in this case, I could see value in introducing a new config variable, similar to preview_path_date_field - curious what you think or if you have a preference either way?

The original proposal from #6801. It feels too verbose, and .year sounds like a field, not a modifier.

I agree with your take here! thanks for the insight!

This matches your option 3, I like it better. If I understand correctly, this is possible if we merge #6690?

I also like this option overall better, and overall I think there'd be value in merging #6690 as is to start supporting filtering in slug configs. some small caveats worth mentioning based on my own minimal unit testing:

• I have yet to verify that change is acceptable for all "formatter" usages of compileStringTemplate
• (may be desired) the change will not see upper supported for slug configs, because we always transform the compiled string to lowercase in slugFormatter

lastly, it appears date handling varies depending on replacement method in stringTemplate#compileStringTemplate (though this behavior may already exist for summary config filtering) - take the following examples, which to my mind should be functionally equivalent in seeing a date field in the entry pulled and filtered as expected (based on minimal unit testing)~

1. slug: "{{date | date("YYYY-MM-DD)}}-{{slug}}" feat(slugs): allow filters in template strings #6690 is sufficient
2. slug: "{{fields.date | date("YYYY-MM-DD)}}-{{slug}}" feat(slugs): allow filters in template strings #6690 is not sufficient

the difference between the above two examples appears to be a difference in string serialization~

• in slug config 1: pulling the date via field replacement in stringTemplate#compileStringTemplate calls getExplicitFieldReplacement, which sees a date field JSON.stringify-ed. dayjs seems to have trouble parsing the result later during filtering because the output is not just the ISOString, which dayjs could handle, but the ISOString with serialized double quotes, i.e. '"2025-10-20T00:00:00.000Z"'
• in slug config 2: we see the date field pulled from the entry as any arbitrary key would be, and cast as string, (which I believe calls toString() on the object under the hood, i.e. 'Sun Oct 19 2025 20:00:00 GMT-0400 (Eastern Daylight Time)')

there could be value in tracking the diverging behavior in date handling in a small follow-up issue - would be happy to file one if you agree these should be functionally equivalent examples!

(I still plan to manually test my change later today, but happy to go for another implementation here or close this in favor of #6690 ! will defer to your insight here. thanks again for the review!)

@martinjagodic finally wrapped up my manual testing~ below are the steps I took:

1. run npm run build on this branch of the repo
2. copy the following files into my website's source directory so I could reference a static, local copy of decap:

fionarowan@MacBookPro decam-cms % cp ./packages/decap-cms/dist/decap-cms.js /path/to/website/src/js/decap-cms.js 
fionarowan@MacBookPro decam-cms % cp ./packages/decap-cms/dist/decap-cms.js.map /path/to/website/src/js/decap-cms.js.map

3. replace reference to official decap package with reference to static local copy in our admin page template:

<script src="/js/decap-cms.js"></script>
<script src="/js/decap-cms.js.map"></script>

4. ensure slug config uses date template tags~ slug: "{{year}}-{{month}}-{{day}}-{{slug}}"
5. run website and decap server against local git gateway backend as per these instructions
6. verify that the file slug's tags {{year}}, {{month}}, {{day}} are populated by the date entered in the entry date widget in the UI

resulting file name

on this branch: _collections/events/2025-11-26-test-future-event-4.md

on main: _collections/events/2025-10-19-test-future-event-4.md